A directory schema is a collection of base content classes and associations. These base content classes and associations abstract tangible and intangible items or “objects” that can be represented in a directory. For instance, a schema may include base content classes that represent computers, peripherals, network switches, operating systems, applications, network connections, people, and so on.
Directory schemas are typically very carefully designed to provide content classes to meet present and future requirements of a directory. However, directory schemas are often extended to meet needs of the directory that were not foreseeable at the time that the schema was designed. For instance, just because one version of a product works with the directory schema, does not mean that other or new product versions or different products will properly function with the schema. Specifically, any variation of the type information required by a product or product versions over time generally results in the need to extend the directory schema to specifically represent each piece of interesting information that a new product or a new version of the product requires to properly operate. Because of this, third parties typically extend directory schemas to create new content classes and attributes.
Conventional practice, however, is to strictly control directory schema updates because modifying a directory schema requires specialized knowledge and can have complex, serious, and far-reaching consequences for customers. For example, extending directory schemas to support specific products and product versions means that these different products and product versions will have mutually exclusive schemas. Thus, a product that was usable with one schema may become unusable with a different schema.
For instance, suppose object X is an instance of class Y. Class Y has an attribute, Z. Therefore, because object X is an instance of class Y, object X can have this attribute defined on it. Assume that X does indeed have this attribute currently defined in it. Now a schema update is performed that modifies class Y by deactivating attribute Z. Note that this change makes the instance of object X invalid because X now has an attribute, Z, that it is not allowed to have according to the class definition of Y (of which object X is an instance).
Additionally, directory schema extensions or additions are not reversible and always add to the size of the schema. In other words, once a class or attribute has been added to the schema it cannot simply be removed from the schema once it is no longer required. Continuous schema growth due to schema extension results in a problem that is generally referred to as “schema bloat”.
The size of a directory schema or schema bloat becomes relevant when considering that schema changes are global to a distributed computing environment. An extended schema needs to be globally replicated to every domain server on the network. I.e., a distributed directory shares a common directory schema for the entire forest of directory trees that are organized as peers and connected by two-way transitive trust relationships between the root domains of each tree; when the directory schema is extended, the forest is extended.
The collection of data that must be copied across multiple servers (i.e., the unit of replication) during schema replication is the domain. A single domain may contain a tremendous number or objects (e.g., millions of objects). Thus, schema extensions typically result in a substantial amount of replication traffic across the globe on multiple servers—and the larger the schema, the larger the amount of replication traffic.
Moreover, schema replication procedures may result in replication latencies across servers in the distributed environment, causing temporary inconsistencies between various server versions of the schema. For example, consider that a new class A is created at server X, and then an instance of this class B is created at the same server X. However, when the changes are replicated to another server Y, the object B is replicated out before the object A. When the change arrives at server Y, the replication of B fails because server Y's copy of the schema still does not contain the object A. Hence, Y does not know about the existence of A.
In light of these considerations, it is apparent that schema extensions typically require a substantial amount of computing resources and data bandwidth as well as coordination between network administers to ensure that legacy applications in various domains properly operate with the updated schema. Accordingly, installing products on organizational networks that require directory schema changes can be risky, potentially politically difficult, and a time-consuming process.
The following subject matter addresses these and other problems that are associated with schema extensions.